<?xml version="1.0" encoding="utf-8"?>
<Interchange>
<Envelope>
<FromPartyNumber>8718288066800</FromPartyNumber>
Geef hier het aansluitnummer van het EDI centrum van de webshop partij op. Als de webshop partij geen EDI centrum heeft, dan kan het aansluitnummer van de webshop partij zelf gebruikt worden. Als het bericht direct wordt aangeboden aan de ShopServer of aan de Retail3000 API, dan kan als afzender ook 13x het cijfer 9 gebruikt worden. Er vindt dan geen validatie plaats.
<FromPartyName>Webshop party</FromPartyName>
Voor de herkenning van een bericht is het handig als hier de naam van de webshop partij komt te staan die het bericht verstuurd heeft.
<ToPartyNumber>8716123400000</ToPartyNumber>
Geef hier het nummer op van het EDI centrum van de klant waar het bericht voor bedoeld is. Als het bericht direct via de ShopServer of de Retail3000 API wordt aangeboden dan mag hier 9999999999999 als waarde gebruikt worden. Er vindt dan geen validatie plaats.
<ToPartyName>GRS EDI centrum</ToPartyName>
Voor de herkenning van een bericht is het handig als hier de naam van het EDI centrum komt te staan waaraan het bericht verstuurd is.
<InterchangeReference>Int2018051700001</InterchangeReference>
Elke uitwisseling (verzending) van een bericht krijgt een eigen uniek kenmerk. Er zijn geen voorschriften hoe dit kenmerk samengesteld moet zijn, maar het EDI platform en RetailVista zullen bij opnieuw ontvangen van een zelfde InterchangeReference het bericht als eerder ontvangen beschouwen en gaan overschrijven (of afkeuren als het bericht al verwerkt is). Het is dus zaak om binnen de 'FromPartyNumber' te zorgen voor unieke InterchangeReferences. In de verkooporder wordt de 'InterchangeReference' weergegeven ten behoeve van eventuele ondersteuning.
<InterchangeDateTime>2018-05-17T12:41:30</InterchangeDateTime>
Dit is de datum en tijd waarop de verzending van het bericht gedaan is. Het formaat moet voldoen aan het DateTime formaat voor XML berichten.
<InterchangeTest>false</InterchangeTest>
Bij een bericht kan aangegeven worden dat het om een test bericht gaat. Voor verkooporders wordt hier op dit moment nog geen rekening mee gehouden, maar het is mogelijk dat in de toekomst een aparte workflow voor testberichten zal gaan ontstaan.
</Envelope>
<Messages>
<Message>
<MessageDateTime>2018-05-17T12:41:30</MessageDateTime>
Dit is de datum en tijd waarop het bericht opgesteld is. Het formaat moet voldoen aan het DateTime formaat voor XML berichten.
<MessageReference>802</MessageReference>
Elke 'message' in een bericht krijgt een eigen uniek kenmerk. Dit wordt vooral gebruikt voor support toepassingen om te kunnen verwijzen naar een bepaald bericht gedeelte in een verkooporder bericht. Ook in de verkooporder wordt de 'MessageReference' weergegeven ten behoeve van eventuele ondersteuning.
<HighPriority>false</HighPriority>
Een verkooporder kan als 'Hoge prioriteit' worden gemarkeerd. Voor verkooporders wordt hier op dit moment nog geen rekening mee gehouden, maar het is mogelijk dat in de toekomst een aparte workflow voor testberichten zal gaan ontstaan.
<Header>
<SupplierPartyNumber>8718288066800</SupplierPartyNumber>
Geef hier het EDI aansluitnummer van de webshop partij op. Als dat niet bekend is, dan kan eventueel 13x het cijfer 9 worden opgegeven. Dit is een vaste herkenning voor onze systemen dat de afzender een webshop partij is.
<BuyerPartyNumber>8716123402554</BuyerPartyNumber>
Geef hier het EDI aansluitnummer van de winkel op. Een winkel zal moeten beschikken over een geldig EDI aansluitnummer, anders kan het Retaillink EDI platform het bericht nooit doorsturen naar de juiste bestemming. Als het bericht aan de ShopServer of direct aan RetailVista wordt aangeboden, dan kan als aansluitnummer ook 13x het cijfer 9 worden opgegeven. In dat geval zal een controle genegeerd worden.
<BuyerReference>Order opmerking van klant</BuyerReference>
<Customer>
<CompanyName></CompanyName>
Geef de bedrijfsnaam op, óf de achternaam met eventueel voornaam en tussenvoegsel. Beide is niet toegestaan.
<FirstName>Mark</FirstName>
Vooornaam
<MiddleName></MiddleName>
Voorvoegsel
<LastName>Vroom</LastName>
Achternaam
<StreetName>Thuisadres straatnaam</StreetName>
Geef hier de straatnaam, zonder het huisnummer
<StreetNumber>5</StreetNumber>
Geef hier het huisnummer. Dit veld ondersteund alleen cijfers! (zie de XSD definitie)
<StreetNumberAddOn></StreetNumberAddOn>
Geef hier een eventuele toevoeging aan het huisnummer, bijvoorbeeld letters
<ZipCode>8265AB</ZipCode>
Geef hier de postcode bij het adres. Het gebruik van spaties is niet toegestaan.
<State>Overijssel</State>
Geef hier de provincie aan die hoort bij het standaard bezoekadres van de klant.
<City>Zwolle</City>
Geef hier de plaats aan die hoort bij het standaard bezoekadres van de klant.
<CountryIsoCode>NL</CountryIsoCode>
Geef hier de ISO code van het land aan wat hoort bij het bezoekadres van de klant. Als tabel wordt ISO-3166-1 aangehouden. Deze is onder meer te vinden op Wikipedia.
<LandlinePhoneNumber>038-123456</LandlinePhoneNumber>
Geef hier het optionele telefoonnummer van de klant aan. Als formaat is het regio nummer, gevolg door een - teken en het abonnee nummer gewenst.
<CellPhoneNumber>06-12345678</CellPhoneNumber>
Geef hier het optionele mobiele nummer van de klant.
<EmailAddress>dummy@nedfox.nl</EmailAddress>
Geef het email adres van de klant.
</Customer>
<Delivery>
Optioneel kan er gekozen worden voor een 'eenmalig' afwijkend afleveradres. Als het 'Delivery' segment bestaat, dan zal de volledige inhoud daarvan gevalideerd en verwerkt worden.
<Name>NedFox B.V.</Name>
Geef de naam op bij het afwijkende afleveradres.
<AttentionOf>Mark Vroom</AttentionOf>
Geef een optionele ter attentie vermelding op bij de naam van het afleveradres.
<StreetName>Verlengde Gildenweg</StreetName>
Geef hier de straatnaam, zonder het huisnummer
<StreetNumber>23</StreetNumber>
Geef hier het huisnummer. Dit veld ondersteund alleen cijfers! (zie de XSD definitie)
<StreetNumberAddOn></StreetNumberAddOn>
Geef hier een eventuele toevoeging aan het huisnummer, bijvoorbeeld letters
<ZipCode>8265TX</ZipCode>
Geef hier de postcode bij het adres. Het gebruik van spaties is niet toegestaan.
<State>Flevoland</State>
Geef hier de provincie aan die hoort bij het afwijkende afleveradres van de klant.
<City>Emmeloord</City>
Geef hier de plaats aan die hoort bij het afwijkende afleveradres van de klant.
<CountryIsoCode>NL</CountryIsoCode>
Geef hier de ISO code van het land aan wat hoort bij het bezoekadres van de klant. Als tabel wordt ISO-3166-1 aangehouden. Deze is onder meer te vinden op Wikipedia.
</Delivery>
<OrderDetails>
<RequestedDeliveryDate>2018-05-11T00:00:00</RequestedDeliveryDate>
Dit is de optionele gewenste aflever datum.
<OrderDateTime>2018-05-11T12:41:30</OrderDateTime>
Dit is de datum en tijd van de order.
<OrderReference>Order opmerking van klant</OrderReference>
Een klant kan bij een order nog een eventuele referentie/opmerking plaatsen. Deze wordt uiteindelijk overgenomen in de verkooporder in RetailVista en kan later op een rapportage geprint worden.
</OrderDetails>
<Transport>
<TransportTypeDescription>PostNL</TransportTypeDescription>
Bij een verkooporder hoort een transport type waarmee aangegeven wordt op welke manier een order verzonden moet worden. Vaak worden daar tijdens het maken van de bestelling in de webshop bepaalde kosten aan verbonden. De mogelijke inhoud / codes in dit veld moeten afgestemd worden met de klant; dezelfde codes zullen moeten bestaan als 'type transport' in RetailVista.
<TransportClassificationDescription></TransportClassificationDescription>
<TODO>
<TransportProperties></TransportProperties>
Bij sommige type transporten horen bijzondere eigenschappen. Een voorbeeld daarvan is 'Niet afgeven bij buren'. Het gebruik van 'TransportProperties' zal alleen zin hebben bij het gebruik van een software integratie vanuit RetailVista met een pakketdienst. Momenteel is die er voor Post NL en in mindere maten met DHL. Dergelijke codes hangen nauw samen met de gekozen software integratie en zullen op met een RetailVista consultant moeten worden afgestemd op de specifieke situtatie.
</Transport>
<Payments>
Bij een order kunnen één of meerdere betalingen worden vastgelegd. De aanwezigheid van betalingen op een order is optioneel; als er niet of niet voldoende betaald is zal RetailVista in de verwerking van de order de gebruiker dwingen om de juiste maatregelen te nemen voor het ontvangen van het restbedrag.
<Payment>
<Value>4.95</Value>
Dit is de waarde van een enkele betaling. Dit bedrag zal nooit 0 of kleiner als 0 mogen zijn.
<DateTime>2018-05-11T12:41:30</DateTime>
Dit is de datum en tijd waarop een betaling heeft plaatsgevonden. Vooral bij navraag achteraf bij payment providers is het belangrijk dat deze datum en tijd correct is.
<Reference>Ideal20454233223-02</Reference>
Bij een betaling via een payment provider zal altijd een betaal referentie worden teruggegeven. Die betaalreferentie kan hier worden vastgelegd en wordt uiteindelijk zichtbaar bij de verkooporder in RetailVista. Vooral bij navraag over de status van betalingen of het achteraf retoureren is deze referentie erg belangrijk.
</Payment>
</Payments>
</Header>
<Rows>
<Row>
<Barcode>
Een barcode bij een artikel kan zowel numeriek als alfanumeriek zijn. In dit voorbeeld is uitsluitend gekozen voor een numerieke barcode in het veld 'BarcodeValue'. Een tekst barcode kan via 'BarcodeText' worden opgevoerd, maar dan mag 'BarcodeValue' niet bestaan. Per 'Row' mag dus slechts één van beide velden voorkomen. Overigens is het in uitzonderlijke situaties ook nog mogelijk om te kiezen voor 'ProductNumber' waarbij het artikelnummer wordt gebruikt om aan te geven welke artikel een klant besteld heeft. De voorkeur is echter het gebruik van barcodes.
<BarcodeValue>1234567890128</BarcodeValue>
</Barcode>
<ProductDescription>Demo artikel omschrijving</ProductDescription>
Ten behoeve van de leesbaarheid en supportbaarheid van een bericht is het handig om de omschrijving van het artikel ook te vermelden. Zeker wanneer de barcode (om welke reden dan ook) niet herkend wordt door RetailVista, helpt een goede omschrijving om alsnog het juiste artikel terug te vinden en het bericht alsnog te voorzien van een correcte barcode.
<Quantity>1</Quantity>
Geef het door de klant gewenste aantal van het artikel aan.
<QuantityType>Sku</QuantityType>
Met dit veld wordt aangegeven wat de waarde van het 'Quantity' veld betekent. In geval van 'Sku' wordt een enkele consumenteenheid bedoeld. De andere mogelijkheid is 'Package' waarbij in feite dus één of meerdere verpakkingen bedoeld wordt. Het heeft onze sterke voorkeur om te werken met 'Sku' omdat dan altijd bekend is hoeveel stuks een klant zal ontvangen. Wordt er met een verpakking gewerkt, dan zal RetailVista gaan berekenen hoeveel stuks er in een verpakking zitten, op basis van de inkoop informatie uit het artikel bestand.
<Price>
<GrossSalePriceInclVat>4.95</GrossSalePriceInclVat>
Dit is de bruto prijs, de standaard verkoopprijs inclusief BTW van een artikel.
<NetSalePriceInclVat>4.95</NetSalePriceInclVat>
Dit is de netto prijs, de bruto prijs verminderd met korting, inclusief BTW. Als er eventuele totaalkortingen over de hele order worden gegeven, dan moeten die naar rato worden verdeeld over de produkten in de order, zodat het netto totaalbedrag lager uitvalt.
<SalePriceType>Sku</SalePriceType>
Met dit veld wordt aangegeven of de vermelde prijs een prijs per stuk (Sku) betreft of dat de prijs geldt bij het opgegeven aantal (Quantity). In dat laatste geval zal de prijs altijd gedeeld worden door de 'Quantity' om te komen tot een stuksprijs.
</Price>
</Row>
</Rows>
<Footer />
</Message>
</Messages>
</Interchange>